home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 2753 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 23 Jan 1996 19:07:08 +0100
  6. Organization: dis-
  7. Message-ID: <4e384c$13j@serpens.rhein.de>
  8. References: <DLAA61.2us@inter.NL.net> <4dh2dm$jui@serpens.rhein.de> <1292.6592T166T2158@algonet.se> <4do01q$fmc@serpens.rhein.de> <19960120.7B57BE0.122A3@asd01-04.dial.xs4all.nl> <4dtg0e$1j7@serpens.rhein.de> <19960123.7B89070.14DD@asd07-10.dial.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. jtv@xs4all.nl (Jeroen T. Vermeulen) writes:
  12. >>
  13. >> Actually the problem is that the flag MEMF_PUBLIC was never used for
  14. >> anything and wasn't thought out well.
  15.  
  16. >AFAIK it is commonly used (and used properly) by applications, and the
  17. >distinction is relevant for VMM.
  18.  
  19. It is used. Sometimes properly, sometimes not. Sometimes it is used
  20. without reason. This comes from the fact that it has two meanings
  21. (locked memory and shared memory) and it was never checked by the OS.
  22.  
  23. >What is probably meant is that deadlocks must be prevented, where memory is
  24. >swapped out that needs to be present in real mem for the swap mechanism as a
  25. >whole to work.  Of course the task list etc. must also be kept consistent during
  26. >Forbid().
  27.  
  28. And more. There is data used within interrupts. It is rather impossible
  29. to page in data for interrupt code.
  30.  
  31. >It would have to lock, of course.  With `single-threaded' I mean here that only
  32. >one instance of the code could be active at any time (as if it were a task), but
  33. >no actual context switch is made (as if it were a library).
  34.  
  35. As I said this is not possible because the driver may consist of several
  36. tasks that _do_ require context switches. It also is a waste of time
  37. to forbid other tasks to run after one task page-faulted.
  38.  
  39. >You mean separate flag bits for "swappable" and "sharable"?  AFAICS the only
  40. >pools that had to be locked in memory would be:
  41.  
  42. You wouldn't use "bits" for AllocMem but you would declare memory
  43. regions with different properties. There would be new functions to
  44. create memory pools in such regions. AllocMem then would be an
  45. alias to allocate memory from one or more default pools that are
  46. created with the task.
  47.  
  48. > - Private memory allocated by the VM subsystem
  49.  
  50. Most of the VM system itself can be in virtual memory. It even
  51. makes sense as the MMU tables can be pretty big.
  52.  
  53. > - Global shared public mem (eg. public process list)
  54.  
  55. There is no reason to lock shared memory.
  56.  
  57. > - Memory shared between any task and the VM subsystem + VM device driver
  58.  
  59. This has to be locked during the transfer only.
  60.  
  61. >Am I missing another useful application?
  62.  
  63. You haven't named one. The only real memory is needed for a) the
  64. DMA buffers and b) for data used in interrupt code.
  65.  
  66. Since old programs do not declare interrupt code or DMA buffers
  67. this needs some special handling. Most "normal" programs do not
  68. use interrupts or DMA buffers themselves though. That's why it is
  69. possible to tag these programs as VM proof.
  70.  
  71. >Libraries aren't a problem in themselves, because they never leave the caller's
  72. >context unless they're programmed to.
  73.  
  74. That _is_ the problem as they create data that is shared by several
  75. tasks. This data is private to the library though, which means you
  76. need a protected space in the library that can only accessed from within
  77. the library code independent of which task is actually executing it.
  78.  
  79. >Of course, but it must be supported for existing software.  And with the scheme
  80. >outlined above I think it can be, even in such multiprocessor configurations.
  81.  
  82. As I said, Forbid() is not just a semaphore to shared memory.
  83.  
  84.  
  85. -- 
  86.                                 Michael van Elst
  87.  
  88. Internet: mlelstv@serpens.rhein.de
  89.                                 "A potential Snark may lurk in every tree."
  90.